An implementation of the behavior annex in the AADL-toolset Osate2

AADL is a modeling language to design and analyze High-Integrity Distributed and Real-time systems. Embedded sub-languages published as AADL annexes extend an AADL model to enhance analysis. The behavior annex specifies the behavior of an AADL application model. An implantation of this annex allows to perform behavior analysis. In addition, as there are several AADL annexes, the implementation of generic mechanisms to support each one of them is challenging. The behavior annex is a valid candidate to illustrate these challenges by combining several sub-languages. In this paper we expose our experiment to support the behavior annex in the reference AADL toolset OSATE2. This one, supports the AADL version 2 by providing a front-end and a set of analysis plug-ins to analyze an AADL model

Performing Safety Analyses with AADL and AltaRica

AADL and AltaRica languages can be used to support the safety assessments of system architectures. These languages were defined with different concerns and this paper aims at presenting their principles and how they can be related. A translator from AADL to AltaRica is proposed and its prototype is applied to a simplified flight control system of a UAV. The resulting AltaRica model has been analyzed with the AltaRica safety tools and the experimental results are discussed

NO WARRANTY

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty ” statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent

Replaceable Components and the Service Provider Interface

Several popular component-based standards have emerged recently, including JavaBeans and Enterprise JavaBeans from Sun Microsystems and the Component Object Model from Microsoft. These component models are being adopted for use in software development, as they eliminate opportunities for architectural mismatch and are supported by standard services. A highly touted property of component models is that they support the development of replaceable components. Unfortunately, a robust, commercial marketplace of replaceable components has not been established for any of these component models. On the other hand, the properties of the Service Provider Interface (SPI), used in many Java language packages, has resulted in the development of reusable components in several technology areas. Examples of successful SPI packages include Java Database Connectivity, Java Cryptography Extension, Java Naming and Directory Interface, and the Java Application Program Interface for XML Processing. This technical note considers the motivation for using replaceable components and defines the requirements of replaceable component models. It evaluates the properties of standard component models and the SPI approach that affect their ability to support replaceable components